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ABSTRACT 

This technical report describes a, generic 
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^'bites,*' inherits both a knowledgis organization describing the kind 
of knowledge represented and tutoring components that provide the 
fiinctionaiity to accomplish the rtandard tutoring tasks of diagnosis, 
student modeling, and. task selection. The goal of the bite-size tutor 
is an interface that allows the curriculum of a system to be supplied 
by a domain expert who is not a programming expert. Three bite- si zed 
intelligent tutors hav^. been implemented at the Learning Research and 
Development Center at the University of Pittsburgh: il) Bridge: An 
Intelligent Tutor for Programming.; (2) Smithtown: A Discovery World 
for Economics; and (3) Eureka: A Tutor for Hydrostatics Problems* 
Descriptions of these three tutors conclude the report, and 11 
references are listed. (RP) 
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Introduction 



Many projects intelligent computer-based instruction depend upon detailed but general 
theories of human learning or diagnoses of the learner's cognitive state (see, for example, Bonar and 
Cunningham [1986], Ohlsson and Langley [1984] and Van Lehn [1984]). We feel there is also an 
enormous potential for sy^ems based on theory^rivpn analyses of domain expertise. For particular 
fields, for example, cognitive science researchers have developed accounts of skilled performance and 
of impediments to skilled performance. Such accounts could be used to develop useful ar.d interesting 
instructional systems. Widespread development of this kind of tutor would be faciliated by a general 
intelligent tutoring system architecture and tools to support development. In this paper we desribe 
our first steps toward suclvan architecture, called the Bite-Size Tutor. 

The Bite-Size .Tutor is a general intelligent tutoring , system shell that provides the 
curriculum-independent part of an intelligent tutor and specifies an organization for the curriculum 
knowledge,*to be supplied by a domain expert. With* the Bite-Sized Tutor, we can exploit the expert 
system approach currently being applied in many intelligent tutoring system projects. In this 
approach, competent ^performance in a domain is analyzed. Novices learning that domain may be 
observed. The results of these analyses and observations are a "cognitive task analysis" of the domain 
and a "bug catalog" of common novice problems in the domain. "Cognitive task analyses" (Learning 
Research & Development Cejiten May 1986) are analyses beyond a behavioral "rational task 
analysis" that specifically attend .to the underlying cognitive skills and representations involved in 
competent performance. "Bug catalogues" (Brown & Burton, 1978; VanLehn, 1982, 19^3) describe 
systeriiatic errors or misconceptions that are likely to impede learning or skilled performance. Taken 
together, the cognitive: task analysis and the bug catalog constitute the "curriculum" of most 
intelligent tutors. - 

Our key goal with the .Bite-Size Tutor is an interface that allows the curriculum of a system to 
be supplied by a dcmdin expert who is not a programming expert. This is a crucial goal - creating the 
curriculum for any kind of computer based instruction is a demanding and time consuming task, 
running into hundreds of hours of development for each Hour of instruction. The toy domains, 
microscopic curriculums, and limited instructional activities of experimental intelligent tutors must 
be expanded to complete curriculums that jneet recognized instructional needs with an array of 
techniques and. activities for the student. Such an expansion requires extensive input by domain 
experts who are not programmers. We in the intelligent tutoring community must provide the tools to 
allow this approach. 



\ 
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In this article, we , first discuss problems with current intelligent tutoring system 
architectures. We then propose our solution: an architecture that uses the\structures of an 
object-oriented programmjing language as domain-independent modules for intellige^it tutors. We 
discuss the detailed architecture of the Bite-Size Tutor, and illustrate this architecture^A^th several 
examples from projects being developed at LRDCFinally, we touch upon future research directions. 



Problems with current intelligent tutoring systems 

Close examination of most currentintelligent tutoring system implementations shows them 
^ to be complex and unwieldy. (We want to emphasL^e that this discussion is not a criticism of any 
particular intelligent tutoring system, but a general problem that appears in many systems.) Pieces of 
programming code are repeated in several places; closely-related information is spread apart. It might 
appeiar that these difficulties are simply a matter of prototype Implementations, written without 
concern for detailed software engineering issues. While this is part of the problem, theire is a more 
fundamental design flaw, related to the use of knowledge within the intelligent tutoring system. 
Intelligent tutoring systems are usually conceived as a series of semi-independent components like 
"explainer," "diagnoser," "tutor," and "user modeler." the problem is that these components need to 
share many diverse pieces of knowledge. The knowledge needed for different components typically 
overlaps considerably. Functional components whose roles are quite clearly delineated in an abstract 
description of the system may be implemented with code diffused through many parts of the system. 
The systems, therefore, . are not.modular. In particular, they do not; allow for addition of new domain 
knowledge or new approaches to the pedagogical 'tasks. " . 

The WEST tutoi [Brown and Burton, 1982] provides an example of these problems. As one of 
thj most intellectually important "classic" intelligent tutoring systems, it serves as a useful foil for 
this discussion. It can be viewed in two ways: in terms of its "issues" (the fundamental lessons the 
system is prepared to teach the student) ar'd in terms of its components (e.g. "expert," "differential 
modeler," "tutorial selector.") In the actuaMnterlisp-D implementation of the tutor, the program is 
organized by components. Th'ts results in a system with unnecessary duplication and complexity in its 
multiple, overlapping representations of issue knowledge. Besides obscuring the organization of its 
knowledge, the current implementation of WEST makes it difficult to reuse and extend parts of the 
tutor. Given the many open research issues for intelligent tutoring systems, this xs a serious problem. 

In general, we need a tool that enables the development of tutoring systems much more 
rapidly than now^possible. Ideally, such a tool will allow a subject domain expert or a teacher (who is 
not necessarily a programmer) to modify the domain knowledge and the tutor-student interaction. 
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without reimplementing the system at each step. Finally, we need a tool to make it easier for those 
who develop tutors to test their systems as they are designed. 

An Object-Oriented Intelligent Tutoring System Architecture 

We propose to take advantage of the character of an object-oriented programming language to 
develop an architecture that is modular and is therefore both comprehensible and easily modified. 
Object-oriented programming allows, the programmer to create a toolkit oi objects thatt represent items 
of interest in the application area of the program. Objects represent items in the world by containing 
both data, the state of the object, and programs, operations that can change the state. Objects can also 
share structure, with 6ne object defining the structure for several other objects. Such an object is 
called a class. Typically an object specializes a structure it inherits from above, and in turn defines the 
structure for a lower-level set of objects. An object communicates by sending a message to another 
object and requesting some action. An object responds to a message by running one of its programs, 
thereby changing its state or sending new messages to other objects. 

Although objects, x'lasses, inheritance, and messages are the crucial constructs of 
object-oriented programming, the notions of toolkit and protocol are ^central to understanding the 
power of the approach. A toolkit provides a set of objects designed to be specialized and protocols for 
using those objects. Objects in a toolkit p-ovide a range of capabilities designed to be specialized to 
particular application?. A protocol, in the object-oriented sense, is a set of messages that are defined 
for a broad range of objects. For example, we could design a drawing system where objects 
corresponding to rectangles, circles, and characters all responded to the messages d raw, e rase, move, 
etCi Note that each kind of object is free to implement these messages differently. This is -the essence 
of a protocol: a general set of capabilities for simplicity, with a mechanism for accommodating the 
complexityof actual differences. 

Th^ Bite-Size architecture is a toolkit for implementing intelligent tutors. In the Bite-Size 
architecture, everything the system knows is stored in objects. Som^ of these objects will correspond to 
"issues'* in the. sense used by Burton and Brown (1982): things that the systeni can understand and 
talk to the userabout. Many of the different objects representing the domain will sh?,re common 
substructure. For such objects, the standard class inheritance mechanisms of object-oriented 
programming are appropriately used. The critical point is that every thing the system will interact 
with the user about is a separate class. We caU these domain knowledge classes Bites. They are all 
subclasses o^the class Bite. 

Given that we organize the system on the basis of the issues that the system recognizes, where 
are we to put components of the tutor like the "diagnoser," "student model," and "task selector"? We 



provide these components in a generic form as high level objects. So, for example, there are objects 
that can implement a component like a diagnoser. the class Diagnoser will specify the local data 
needed to perform the diagnostic function and the algorithms to use that data. The Diagnoser class 
specification does not specify any particular diagnosis to be done, only the general procedure and data 
required for doing a diagnosis. 

The specific data needed for performing an actual diagnosis are provided when the general 
component classes (e.g. the Diagnoser class just discussed) are inherited by the Bite classes that 
actually need to^use them. Similarly, the other standard intelligent tutoring system components are 
implemented as classes and inherited by the Bites. Consider an example where two kinds of 
diagnosers are to accomplish two styles of diagnosis. This would be handled by having the general 
properties of diagnosers in a class Diagnoser with the specific properties contained in two subclasses 
DiagnoserA and DiagnoserB. Bites are specified to inherit their diagnostic' capability from 
DiagnoserA or DiagnoserB as appropriate. 

The proposed architecture solves the problems described above by making the system highly 
modular. Each curriculum element 5s represented explicitly as a class. To the extent that curriculum 
elements share structure, that sharing is explicitly represented in the inheritance among the classes 
representing these elements. Similarly, each of the key tutoring components is represented as a class 
object. These component classes are used to provide tutoring function to the domtiin classes. Like the 
domain element classes, component classes use inheritance to represent sharedstructure.' 

The Curriculum Elements: Bites 

The structure of the classes representing curriculum element bites is defined by inheritance 
from two kinds of classes. Tutoring component classes, such as the student model and the diagnoser, 
provide a framework in which data must be supplied by the Implementer or curriculum designer. We 
plan to build a non-programming interface itp facilitate defining these bites. Bites also inherit 
structure based on the kind of knowledge they represent. We have defined several classes of bites- 
Abstraction Hierarchy Bites, Definition Bites, Input/Output Bites, and Discovery Bites. In this 
section we discuss each in detail. 

An abstraction hierarchy represents an ordering, of concepts in , the curriculum. In this 
hierarchy specific versions of a concept appear at the lowest level of the hierarchy and more general 
versions of that concept appear higher in the hierarchy. An example of this is shown ih Figure 1. 
There we see the abstraction hierarchies for Ohm/s Law and KirchhofTs Law from our electricity tutor. 
The two highlighted nodes show the relationship between the specific concept, "current is unchanged 



across an uninterupted wire," and the more general concept, "KirchhofTs Law." The "UninterruptedS" 
bite is a specific version of the "KirchofTsLaw" bite and thus is shown at a lower position in the 
hierarchy. 

Abstraction hierarchy bites play an important, organizing role ia the tutors. These bites 
exercise a range of simpler ideas in the curriculum. In electricity, for example, understanding 
KirchhofTs Law implies understanding a collection of more fundamental ideas: circuit geometry (e.g. 
parallel vs. series),. resistor behavior, battery behavior, current, resistance, and voltage. Because of 
this organizing role, the problems abstraction hierarchy bites generate are critical for the diagnosis of 
student performance. Only abstraction hierarchy bites have sufficient perspective (i.e. connection to 
other bites representing fundamental ideas) to test the student's performance in problems that 
integrate across several bites (Lesgold & Ivill, 1987). Implementing this perspective is a current area 
of active research. Our initial work is presented in the section on tutoring components. 
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Fi^re i. Abstraction Hierarchy from the Electricity Tutor 



Definition Bites represent concepts that the student is to learn without being taught much 
background. Examples of this would be the concept of gravitational force as it is used in our tutor for 
hydrostatics (Archimedes's Principle). It's important for the student dealing with buoyancy to 
understand how gravity works, but it's not important to know why it works that way. 

Input/Outpufc Bites represent concepts that^have a black-box behavior. The student needs to 
know that certain inputs produce certain outputs and-needs to^kno w the rule (formula) describing the 
behavior. The student does not need to know the justification for the behavior. The behavior of a 
resistor in an electric circuit is best represented in an I/O bite. 



Discovery Bites enable several of our tutors to combine the advantages of student-initiated 
learning in discovery worlds with support for students who leek the skills to learn efficiently from a 
pure discovery world. These tutors provide a simulation of some aspect of a domain. The intelligent 
tutoring system allows the student to explore the simulation freely until it decides the student is 
floundering, then it makes a suggestion. Discovery Bites represent the inquiry skills, An example of 
this type of bite is "vary only one variable while holding all else constant." [Shute and Bonar, 19861. 



Tutoring Components: Diagnoser 

There are three main tutoring components of the bite-sized tutoring architecture: the 
Diagnoser, the Student Model, and the Task Selector. We discuss each component in turn. The 
Diagnoser is invoked by some event that occurs during the tutoring session. The implementor of a 
specific tutor deter ti. es what events invoke the Diagnoser. In particular, we want to allow for 
different grain-sized observations of the student, ranging from making a diagnosis only when a 
student completes a problem to making a diagnosis based on the s'.udent's movement of the mouse 
every n milliseconds. 

The Diagnoser class is best illustrated in our implementation of the Electricity tutor. Consider 
what happens when a . student responds to a problem constructed at some intermediate bite in the 
KirchhofTs Law abstraction hierarchy. That problem has been constructed from a number of 
component bites representing the fundamentals needed to understand the abstraction hierarchy bite. 
For example, a bite in the KirchhofTs Law abstraction hierarchy constructs problems based on 
component bites concerning resistors, current, circuit geometry, etc. 

Once the system has a student response to a problem, the abstraction hierarchy bite begins a 
diagnosis. Using capabilities provided by the Diagnoser class,' the bite sends a message to each 
component bite asking if the domain knowledge in the component bite is relevant to the student's 
response, current tutoring goals, and the current tutoring mode. If it is, the Diagnoser then checks to 
see if the student is misusing the concept taught by this bite. "Misuse" is defined by a specific 
diagnosis algorithm operating on the specific data of that bite. The Diagnoser then updates the 
student model accordingly. Note that the data for the student model are, of course, stored in the bites. 
When the Diagnoser has completed updating the bites, it invokes the Task Selector to choose what it 
should do next. 



. Tutoring Components: The Student Model 
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The Student Model maintains several components relevant to representing student 
performance. First; the Student Model contains a record of the events of the session. This is stored in a^ 
class variable of,the Bite class so that all curriculum bites (which are instances of subclasses of Bite) 
have access to one copy of it. In addition, the Student Model specifies a series of instance variables 
that represent student performance on individual bites. We currently use a differential modeling 
scheme where we keep three separate measures of the student's success with each bite. One is a 
measure over the entire tutoring session, one is a measure over the the last five events, and the last is 
a measure of the Idst (or current) event. These me&sures are ratios of how many times the concept of 
each bite was used appropriately by the student, divided by how many times it should have been used 
as determined by the Diagnoser. 

Tutoring Components: The Task Selector 

The basic flow of control of the tutor is based on Tutoring Mode objects stored in a stack located 
in a global object Tutoring Session. Tutoring Mode instances set the local state for a series of 
instructional tasks. The Tutoring Mode has^two instance variables useful to the Task Selector. One 
indicates criteria for the mode being satisfied, and one indicates-some threshold for deciding that the 
student is floundering and currently unable to learn the current concept in the current mode. 

Each mode object defines several messages. The Initialization message initializes the two 
instance variables mentioned above, based on the current student model. A Process message teaches 
the relevant bites in a manner consistent with the current mod,e (see below). A Satisfaction message 
will determine if the current modo is satisfira and what steps are to be taken when it is. It usually 
means popping the present mode^stance :Tthe Tutoring Ses^on. stack and pushing a new mode 
instance on the sf.ack. A Threshold message decides what actions to take when the student shows 
evidence of not being able to satisfy the mode object. This will usually initiate pushing some.remedial 
mode object onto the stack. - 

The Task Selector first ^xamines the stack. If it is empty the Task Selector creates a new 
instance of some default mode and sends the local Initialization message to the mode. The Task 
Selector then returns the control to the student. If the stack is not empty, the Task Selector sends the 
Satisfaction message. If the current mode is not satisfied, the Threshold message is then sent. Finally, 
if the threshold condition is not met the Process message is sent. 

Tutoring modes describe the type of tutor-student interaction that is currently being used. We 
are'implementing six of thestj modes: 
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-Exploration The student is obtaining information from the discovery world in 
order to refine and complete developing hypotheses. 

•Experimentation - The student is performing sorne action designed to confirm or 
diiTerentiate hypotheses, whether explicitly stated or recognized by the tutor. 
-Elaboration - The student is testing some previously confirmed hypothesis. 
-Didactic - The tutor is driving the interaction by proposing problems for the 
students 

-Demonstration - The tutor takes over and demonstrates some concept explicitly. 
-Coaching - The tutor provides some hints that will help the student understand the 
bites in question. | 

Example Bite-Si^ed Intelligent Tutors 

Bridge: An Intelligent Tutor for Programming 

; 

Briuge is a tutor that teaches computer programming. In Bridge^ the student user is presented 
with problems of a complexity appropriate to the first ten weeks of an introductory programming 
course. Bridge coaches the student through three phases of problem*solving for each problem posed. 
In the first phase, the student constructs a set of step-by-step instructions by choosing and arranging 
informal English phrases. In the next phase, . the student matches these phrases to visual 
representations of programming schemata we call ''plans" [Soloway et al., 19821 and combines the 
representations to build a runnable program. In the final phase, the student uses the visual 
representation as a guide to building a correct programming languaga solution to the original 
problem. Currently Bridge tutors Pascal, other programming languages could be tutored using the 
same approach. 

In the current Bridge implementation (Bonar & Cunningham, 1986) the 
curriculum-dependent bites are the programming plans and the plan specializations needed for each 
problem that Bridge can tutor. These plans fit into an abstraction hierarchy with the problem-specific 
programming plans at the lowest level of the hierarchy. The Diagnoser determines whether a 
particular bite is being used appropriately by comparing the student's current program with the 
requirements specified for that plan ]n the current phase. This information is represented by a 
requirements^ language that defines a group of operators which indicate various things about the 
planSy the correct order of their appearance, and their relationships to each other. Figure 2 shows an 
example of this language. This example shows some of the requirements of the Counter Variable Plan 
in Phase 1 for the Ending Value Averaging Problem. 



12 



O&Jit of expression : 



(PushToHighest UVAPCounterVariAblePVan 
Exists? 

(Hints (In order -to coiipute the average, ' 
ydu will need to divide the ^um 
of the Integers by. the nu«ber of 
Integers read In. Include a plan 
to read 1n the nuaber of 
Integers. ) 
(To cOMpute the' aver^^ge, you. Must . 
divide the 3um of all the 
Integers read lh >/ the 'count of 
the nuiiber of ./integers. Include 
the %"Keep coiint of ... plan 
now.))) // 
(EVAPCounterVarlablePlan Sequence/. . . 

EVAPInput«evValueVarl6blepian ... 
C^.APCounterVarlablePlan / .. 
(Hints ^You have to acquire the nuabers 
BEFORE you^can count theoi.) 
(Put the stop ydij use to acquire the 
nuibers above the step you use to 
count then.) 
(Put %"Keep count of . . plarv-below 
the %"Read In . . 

or y^-Get plan.))) 

(AnyOf (EVAPCounterVarlablePlan Sequence ... 

EVAPCounterVarlablePlan ... 
EVAPResultOutputPlah ...) 
(EVAPCounterVarlablePlan Sequence ... 
EVAPCounterVarlablePlan ... 
EVAPResultValuePlarv . .-.) 
(Hints (You Must count the nunbers BEFORE you 
can coMpute the average.) 
(Put the stateiTeni you use to count 
the nuMbers higher than the one 
you use to compute the average.)) 

» 



Figurt 2. RequiremenU Langutge from Bridgn 



Some of the requirements languagp operators we have found useful are: 



-Sequence - this de^crib^s the order in which the plans should appear in the 

i 

program. Figure 2 shows three such sequence requirements. The that separates 
some plans indicatels that zero or mortf plans can come between theni in the 
student's solution. 

-Exists? " This operator indicates that the plan mentioned must appear in the 
program. In figure 2, the Counter Variable Plan is required to be in the program. 
-AnyOf - this is the equivalent of an OR operator. It is satisfied if any of its 
arguments is satisfied. 

-All this is the equivalent of an AUU operator. It is satisfied only if all of its 
arguments are satisfied. 

-Not - this is the usual NOT operator. It is satisfied only if its argument is not 
satisfied. 

-PushToHighest - This manages several requirements at once and selects a hint 
dealing with the first unsatisfied plan. - ' - 
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Figure 3. Bite Hierarchy for Smithtown. "InterrogationBite" is a class of Discovery Bites. 



Smithtown: A Discovery World for Economics 



The economics discovery^world simulates an imaginary town which conforms to the laws of 
supply and demand. The student controls several variables, e.g. population, income per capita, 
interest rates, consumer preference, number of suppliers, and weather. The student changes one or 
more of these variables and observes the resultant change on the other variables of the world. The 
student has several tools to aid discovery, e.g. a notebook to, record the changes observed in the 
variables and a graph package to observe relationships between variables. In addition to teaching an 
economics curriculum, the tutor teaches scientific discovery skills, so some of its bites are discovery 
bites (see Figure 3). The economic3 curriculum bites will teach about the patterns in the data collected 
by the students as they explore the micro world. ' t'' 

/ 

/ 
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Eureka; A Tutor for Hydrostatics Problems 

' Eureka employs an exploratory microworld environment that demonstrates the principles of 
buoyancy pertinent to Archimedes* Principle (Klopfer, 1985). The mode of learning is very similar to 
the economics tutor. The student explores the microworld, makes hypotheses when he or she discovers 
some relationship, and then tests those hypotheses with subsequent experiments. The student has the 
ability to change several'variables in the "laboratory" environment: the mass of the block, the density 
of the liquid, the gravitational force, etc. He has the same tools available to aid his exploration that 
were.described above in the economics tutor. 




^^igure 4 shows the inheritance lattice for Eureka. This tutor is very similar in structure to the 
economics tutor. It uses discovery bites to tutor useful scientific skills. It has-bites that teach about 
observable patterns in the data collected during the session. 
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Concluding Remarks 

We have illustirated a generic architecture for building intelligent tutoring sy'''''^ms. In 
particular, we have focused on techniques for domain independent representation of the 5 vledge to 
be taught. The key idea is to organize the tutor around objects that represent the knowledge to be 
taught^ not around the various components of the tutor. 

i. . 

Although each of the tutors discussed is implemented, very little code is actually shared 
between them. We are currently reimplementing several of the tutors to share code for all the basic 
components and knowledge organizations. We have also begun working with non-programming 
domain experts in.designing an interface to let them design the tutor*s curriculum. 
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